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Abstract 

This  paper  introduces  a concept  for  building  up 
distributed  monitoring  and  diagnostic  systems 
for  complex  industrial  applications.  The  diag- 
nostic process,  from  accessing  sensor  data  up  to 
the  visualization  within  a graphical  user  inter- 
face is  described  by  universal  applicable  for- 
malisms. Generic  mechanisms  were  identified  to 
improve  the  quality  of  a diagnosis  by  integrating 
legacy  diagnostic  engines  and  handling  different 
diagnostic  mechanisms  in  parallel.  For  this  pur- 
pose, a modular  multi-agent  architecture  and  a 
set  of  development  tools  were  implemented. 

This  software  architecture  for  monitoring  and 
diagnosis  was  developed  within  the  framework 
of  the  EU  Esprit  Program:  “DIAMOND:  Dis- 
tributed Architecture  for  MONitoring  and  Diag- 
nosis”. 

1 Introduction 

To  compete  within  industry,  manufacturers  are  demanded 
to  optimize  their  productive  processes.  In  order  to 
achieve  this  efficiency,  a high  value  has  to  be  set  on  the 
quality  of  the  industrial  equipment  as  well  as  on  the  in- 
dustrial process  itself  Monitoring  and  diagnostic  systems 
(M&D  systems)  support  this  objective  by  predicting  fail- 
ures, or  if  a failure  occurred,  by  identifying  the  reason 
for  this  fault.  Thereby  it  is  possible  to  reduce  down-time 
costs  of  the  production  process.  To  achieve  an  overall 
reduction  of  the  production  costs,  the  development  ex- 
pense for  a powerful  M&D  system  has  to  be  minimized. 
For  this  purpose,  a modular  concept  was  realized  that  is 
based  on  a distributed  multi-agent  approach. 

A complex  industrial  application  is  built  by  a set  of  dif- 
ferent physical  units.  These  units  may  be  provided  by 
different  vendors,  having  detailed  knowledge  about  the 
behavior  of  their  unit.  Furthermore,  there  are  often  dif- 
ferent diagnostic  methods  for  the  same  unit  available.  To 
realize  a powerful  diagnosis,  the  knowledge  about  the 
different  physical  units  and  about  various  diagnostic 
methods  should  be  merged  together  within  an  overall 
framework.  Therefore,  new  strategies  were  required  to 


treat  these  supplementing  diagnostic  knowledge  about  an 
industrial  process. 

This  paper  presents  the  generic  aspects  of  the  underlying 
infrastructure  and  describes  the  multi-agent  framework. 
It  is  neither  deemed  to  explain  any  diagnostic  algorithms 
that  may  be  applied  nor  to  present  the  methodologies  in 
detail  that  are  employed  to  handle  different  diagnostic 
results  in  parallel. 

2 Related  work 

Interest  in  recent  research  on  distributed  approaches  for 
diagnostic  purposes  can  currently  be  seen  in  Europe, 
Japan  and  in  the  United  States.  A general  overview  about 
distributed  artificial  intelligence  in  industry  is  given  in 
[Par94].  This  paper  reviews  the  industrial  needs  for  Dis- 
tributed Artificial  Intelligence,  giving  special  attention  to 
systems  for  manufacturing,  scheduling  and  control.  It 
gives  case  studies  of  several  advanced  research  applica- 
tions, actual  industrial  installations  and  identifies  steps, 
need  to  be  taken  to  deploy  these  technologies  more 
broadly. 

In  [Fro96]  there  is  a distinction  between  semantically 
distributed  diagnosis  and  spatially  distributed  diagnosis. 
Semantically  distributed  diagnosis  refers  to  a heteroge- 
neous group  of  agents,  in  which  each  agent  has  its  own 
view  of  the  system.  This  can  either  mean  that  each  agent 
focuses  on  a specific  area  of  the  system  or  that  the  agents 
model  different  aspects  of  the  system  or  use  different 
diagnostic  methods,  e.g.  one  agent  models  the  structure 
of  the  system  and  another  one  models  the  performance. 
Spatially  distributed  diagnosis  refers  to  a group  of  agents 
which  jointly  monitor  and  diagnose  a spatially  distrib- 
uted system  with  relationships  between  those  equip- 
ments. Each  agent  has  detailed  knowledge  about  a small 
part  of  the  system. 

Different  concepts  to  realize  a distributed  approach  are 
proposed  in  the  literature,  ranging  from  classical  client 
server  application  over  blackboard  technologies  to  a few 
multi-agent  frameworks.  Most  distributed  applications 
employ  a classical  client  server  approach  with  distributed 
clients,  communicating  with  a central  server.  This  well 
known  technology  Is  continuously  advanced  and  applied 
to  distributed  management  applications.  The  standardi- 


zation  of  distributed  management  tasks  like  information 
exchange,  monitoring  and  diagnostics  is  aimed  by  the 
Common  Diagnostic  Model  (CDM),  developed  within 
the  “distributed  management  task  force”  (DMTF) 
[DMTF],  This  framework  is  based  on  software  clients 
which  perform  their  tasks  nearly  automatically  and  report 
information  to  a central  server. 

Another  concept  is  based  on  a blackboard  technology.  A 
central  blackboard  is  used  to  store  all  available  informa- 
tion about  an  industrial  process.  These  data  can  be  ac- 
cessed by  other  software  units,  possibly  software  agents, 
in  order  to  perform  a diagnosis  or  to  visualize  the  results. 
[Lee97]  outlines  the  conceptual  foundations  for  next 
generation  industrial  remote  diagnostics  and  product 
monitoring  systems.  It  extends  the  multi-agent  frame- 
work research  to  include  new  classes  of  product  popula- 
tion and  diagnostic  agents  within  a distributed  Embedded 
Web  and  Electronic  Commerce  infrastructure.  The  prod- 
ucts to  be  diagnosed  are  for  example  printers,  copiers 
and  vehicles. 

[Ben97]  introduces  a KQML-CORBA  (Knowledge 
Query  and  Manipulation  Language)  [KQML]  based  ar- 
chitecture to  implement  a multi-agent  system  for  network 
and  service  management.  The  paper  adopts  this  archi- 
tecture and  applies  it  to  diagnosis  and  monitoring  of  ma- 
chines and  components  in  the  production  environment  by 
using  a multi-agent  approach,  combined  with  semanti- 
cally distributed  diagnosis.  Up  to  now  there  are  only  few 
other  implementations  of  KQML,  one  over  TCP/IP  in  C 
which  has  been  developed  Lockheed-Martin  [Fin99]  and 
one  in  JAVA  [Fro96].  The  use  of  the  agent  communica- 
tion language  developed  by  FIPA  [FIPA98]  together  with 
the  CORBA  standard  for  distributed  computing  is  a 
widely  used  strategy  to  realize  an  agent  interaction 
[Orf97]. 

3 Units  of  Monitoring  and  Diagnostic 
System 

High  value  and  cost  effective  diagnosis  system  can  be 
developed  by  distinguishing  between  the  tasks  that  have 
to  be  performed  within  a M&D  system.  Some  tasks  are 
general  for  all  monitoring  and  diagnostic  systems,  some 
are  specific  for  the  employed  production  equipment  and 
others  are  specific  for  the  considered  production  process. 
These  three  units  should  to  be  treated  in  different  ways: 

3.1  Generic  M&D  units 

Independent  to  specific  requirements  of  an  application 
area,  a set  of  tasks  are  generic  for  all  monitoring  and 
diagnostic  systems.  Functionalities  like  interfacing  dif- 
ferent units,  storing  data,  formatting  measurements  and 
diagnosis  results,  configuring  the  system,  managing  the 
interaction  and  some  more  have  to  be  performed  in  all 
M&D  systems.  It  is  obviously  feasible  to  reuse  a set  of 
existing  software  units  whenever  a specific  Monitoring 
and  Diagnostic  system  has  to  be  built.  This  allows  the 
integration  of  highly  developed  and  well  tested  units  ex- 


tremely fast  and  low  priced.  Together  with  a set  of  well 
defined  interfaces,  a general  architecture  for  monitoring 
and  diagnosis  becomes  realized. 

3.2  Specific  to  production  equipment 

Some  parts  of  monitoring  and  diagnostic  software  are 
specific  to  the  used  production  equipment.  The  way  how 
to  access  sensor  values  and  how  to  use  these  data  to  di- 
agnose a physical  component  is  specific  to  the  produc- 
tion environment.  The  component  manufacturer  is  inter- 
ested to  equip  its  component  with  monitoring  and  diag- 
nostic capabilities  that  are  compatible  with  a generic 
architecture.  The  usage  of  software  agents  allows  to  en- 
capsulate legacy  diagnostic  tools  in  order  to  become  in- 
teroperable to  the  overall  system  (see  section  5).  These 
parts  are  reusable  whenever  the  same  production  equip- 
ment is  used  and  should  not  be  developed  each  time  a 
M&D  system  is  built  from  scratch. 

3.3  Specific  to  production  process 

All  remaining  parts  of  the  complete  monitoring  and  di- 
agnosis system  are  specific  to  the  production  process. 
The  interaction  between  different  physical  components, 
and  adoptions  of  the  operator  interface  are  examples  for 
units  that  have  to  be  develop  individually. 

4 DIAMOND  - distributed  multi- 
agent architecture 

The  architecture,  proposed  in  this  paper,  tries  to  merge 
the  three  different  parts  to  a consistent  monitoring  and 
diagnosis  system.  All  generic  units  of  a M&D  system  are 
realized  by  the  utilization  of  software  agents,  each  re- 
sponsible for  a specific  task.  An  integration  of  all  parts 
that  are  specific  to  the  production  environment  or  to  the 
production  process  itself  is  supported  by  encapsulating 
these  functionalities  into  different  agents,  able  to  interact 
with  the  overall  framework.  The  DIAMOND  architecture 
specifies  the  information  that  are  required  to  integrate 
these  parts  and  supports  the  development  process  by  of- 
fering a set  of  tools  (see  section  5). 

The  structure  and  the  interaction  of  the  software  agents 
that  are  able  to  perform  all  generic  tasks  and  that  are 
used  to  encapsulate  all  specific  tasks  are  described  in  the 
following  chapter. 

4.1  Structure  of  DIAMOND  Agent 

All  agents  that  are  used  within  DIAMOND  are  built  of 
two  different  software  units.  One  is  responsible  for  the 
communication  with  other  DIAMOND  agents  within  the 
M&D  framework.  This  unit  is  called  ‘Wrapper’  and  is 
identical  for  all  agents.  The  second  software  unit  is 
called  ‘Brain’.  This  part  performs  all  tasks  that  are  spe- 
cific for  the  type  of  the  agent. 

The  Wrapper  is  responsible  for  handling  the  communi- 
cation of  this  agent  with  other  agents  in  the  M&D  system 
by  applying  the  CORBA  middleware.  Information  can  be 
exchanged  by  applying  CORBA  events  or  by  using 


CORBA  call-backs.  The  wrapper  registers  its  CORBA 
objects  at  the  ORB  to  become  visible  for  other  agents. 
However,  the  wrapper  does  not  initiate  or  analyze  any 
information  exchange  with  another  agent  by  itself.  This 
is  handled  by  the  brain  part. 

The  agents  brain  performs  all  tasks  that  are  specific  to 
the  type  of  the  agent.  Some  of  the  agents  that  are  utilized 
within  the  framework  perform  exclusively  generic  tasks 
that  are  similar  for  all  industrial  environments.  The  im- 
plementation of  the  brain  for  these  agents  is  uniform  for 
each  application  where  DIAMOND  is  applied.  The  tasks 
that  have  to  be  performed  by  the  monitoring  and  diag- 
nostic agents  (see  next  chapter)  are  partly  independent 
on  the  application.  One  part  handles  generic  monitoring 
or  diagnostic  capabilities.  This  part  of  the  monitoring 
agent  brain  and  the  diagnostic  agent  brain  is  provided  by 
the  DIAMOND  development  toolkit  (see  section  5.4  and 
section  5.5).  All  further  capabilities  depend  on  the  spe- 
cific application  and  have  to  be  implemented  afterwards 
individually  by  accessing  well  defined  interfaces.  This 
absence  of  an  explicit  implementation  enables  the  inte- 
gration of  legacy  monitoring  and  diagnostic  tools  inside 
the  brain  of  a monitoring  agent  or  inside  a diagnostic 
agent. 

4.2  Agent  interaction 

The  Wrapper  of  each  agent  uses  CORBA  to  exchange 
messages  with  other  agents.  It  supports  a synchronous 
call-back  communication  and  an  asynchronous  event- 
based  communication. 

The  wrapper  exposes  a CORBA  remote  interface  to  other 
agents  that  can  use  it,  whenever  they  want  to  send  a mes- 
sage to  this  agent  by  using  a CORBA  call-back.  The 


cure,  if  an  unknown  protocol  was  received,  if  the  agent  is 
to  busy  to  handle  the  message  or  if  the  agent  will  con- 
tinue to  process  the  message.  Only  in  the  last  case,  the 
message  will  be  stored  in  an  internal  buffer  that  is  part  of 
the  Wrapper.  This  buffer  allows  to  sort  incoming  (and 
outgoing)  messages  according  to  their  priority,  their 
timestamp  or  in  respect  to  a given  time-out.  The  brain 
removes  the  message  from  the  buffer  as  soon  as  it  is  able 
to  process  it.  After  processing  the  message,  it  specifies 
the  answer,  corresponding  to  the  used  protocol.  This  an- 
swer is  stored  in  the  internal  buffer  of  the  agent  and  for- 
warded to  the  remote  CORBA  object. 

The  message  that  is  sent  by  an  agent  contains  a set  of 
pre-defmed  parameters  as  it  is  specified  by  FIFA.  These 
parameters  are  stored  within  a XML  structure.  Since  a 
conversation  must  not  only  handle  information  exchange 
but  also  the  exchange  of  attitude  about  the  information,  a 
2-layered  protocol  is  applied.  The  outer  layer  of  a mes- 
sage represents  the  attitude  about  the  information.  These 
data  are  processed  by  the  Wrapper.  The  information  it- 
self is  part  of  an  inner  layer  which  is  stored  in  the  con- 
tent parameter  of  a message.  The  message  content,  which 
is  also  encoded  in  the  XML  syntax,  is  processed  by  the 
brain  of  the  agent. 

If  an  agent  wants  to  supply  data  quickly  to  the  overall 
multi-agent  framework  without  taking  care  about  the  re- 
ceiving agents,  an  asynchronous  event-based  communi- 
cation is  more  feasible.  This  mechanism  is  mainly  used 
by  the  monitoring  agents  to  supply  measurements  to  all 
diagnostic  agents  that  are  interested  in.  Every  agent  is 
able  to  supply  and  to  consume  events,  structured  in 
XML,  by  connecting  to  different  event  channels.  This 
CORBA  functionality  is  accessed  by  the  Wrapper. 
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Figure  1 Agent  Interaction 


FIPA-Agent  Communication  Language  (FIPA-ACL) 
[FIPA98]  is  used  to  restrict  the  interaction  between 
communicating  agents  (see  figure  l).The  REQUEST,  the 
QUERY-REF  the  SUBSCRIBE  and  the  CANCEL  proto- 
col were  identified  to  cover  all  required  agent  interac- 
tions. The  call-back  CORBA  concept  allows  the  receiv- 
ing agent  to  return  an  integer  value  instantly  if  the  struc- 
ture of  the  message  is  invalid,  if  the  message  is  not  se- 


4.3  Monitoring  Agent 

The  interface  between  the  physical  state  of  the  industrial 
application  and  the  DIAMOND  system  is  realized  by  a 
Monitoring  Agent.  This  type  of  agent  handles  the  meas- 
urements of  the  physical  components  and  prepares  them 
to  be  treatable  by  other  agents  within  the  framework. 
Each  Monitoring  Agent  has  to  be  adjusted  to  the  sensors 


of  the  industrial  equipment  that  will  provide  the  meas- 
urements. Furthermore,  the  Monitoring  Agents  are  able 
to  initiate  a diagnosis  of  a component  as  soon  as  they 
have  identified  an  irregular  state  of  a measurement. 

4.4  Diagnostic  Agent 

Different  aspects  of  distribution  are  handled  within  the 
DIAMOND  framework.  First  of  all,  the  different  tasks 
that  have  to  be  performed  within  the  monitoring  and  di- 
agnostic process  are  distributed  to  different  agent  types, 
each  responsible  for  its  specific  task.  The  task  that  has  to 
be  performed  by  the  Diagnostic  Agents  is  also  distrib- 
uted again.  The  Diagnostic  Agents  are  handling  the 
measurements  that  are  provided  by  the  Monitoring 
Agents  to  identify  the  functional  state  of  the  physical 
components.  This  diagnosis  may  be  performed  by  differ- 
ent Diagnostic  Agents,  each  having  a different  view  of 
the  industrial  application. 

• This  variation  may  be  related  with  different  temporal 
aspects  of  the  behavior  of  the  plant  (temporal  distri- 
bution). 

• Often,  there  are  different  diagnostic  algorithms 
available  to  identify  the  state  of  an  industrial  proc- 
ess. A development  tool  for  a flexible  M&D  system 
has  to  be  able  to  handle  various  diagnostic  mecha- 
nisms in  parallel.  This  is  identified  as  a semantical 
distribution  of  the  diagnosis. 

• The  entire  diagnostic  knowledge  about  the  behavior 
of  the  plant  is  split  to  a set  of  smaller  knowledge 
units,  each  associated  with  a physical  part  of  the 
plant,  called  component.  A single  Diagnostic  Agent 
does  not  know  about  the  behavior  of  the  complete 
plant,  but  about  a single  component.  This  knowledge 
may  be  provided  by  the  manufacturer  of  the  compo- 
nent. In  this  manner,  the  diagnostic  task  is  spatially 
distributed. 

When  distributing  the  overall  diagnostic  task  regarding 
temporal,  semantical  and  spatial  aspects,  a flexible  and 
clear  framework  is  feasible.  For  diagnosing  the  overall 
process,  the  various  diagnostic  results,  reported  by  dif- 
ferent Diagnostic  Agents  have  to  be  merged  together. 
This  additional  task  is  performed  by  the  Conflict  Reso- 
lution Agent. 

4.5  Conflict  Resolution  Agent 

A conflict  resolution  mechanism  is  required  to  investi- 
gate, whether  the  diagnostic  results,  reported  by  different 
Diagnostic  Agents  are  contradicting  or  completing  each 
other.  The  Diagnostic  Agents  do  not  communicate  with 
each  other  to  merge  their  knowledge,  but  do  report  their 
diagnosis  to  a Conflict  Resolution  Agent.  According  to 
the  different  types  of  distribution,  temporal,  semantical 
and  spatial  conflicts  have  to  be  considered.  For  this  pur- 
pose, the  relations  between  the  components  and  between 
the  possible  failures  which  may  be  related  within  the 
components  have  to  be  well  known  (section  5.1  and  5.3). 
The  knowledge  is  represented  by  a Graph.  An  adjacent 
vector,  where  each  element  represents  a component  is 


used  to  build  the  graph  [ALG94].  Each  node  (compo- 
nent) consists  of: 

• Vector  of  topological  arcs  with  other  components 

• Vector  of  relationships  between  the  same  failure  in 
different  components 

• Vector  of  relationships  between  different  failures  in 
different  components. 

The  overall  conflict  resolution  process  is  divided  into 
different  sequential  steps: 

• The  reported  failures  are  assigned  to  the  nodes 
(components)  of  the  graph  conformed  by  the  infor- 
mation specified  in  the  structural  knowledge  base 
(chapter  5.1).  This  allows  to  identify  semantical  con- 
flicts. 

• Following,  spatial  and  temporal  conflicts  are  investi- 
gated in  three  different  levels.  Level  1 works  with 
the  topological  information  specified  in  the  struc- 
tural knowledge  base,  level  2 works  with  the  rela- 
tions between  the  same  failure  in  different  compo- 
nents (i.e.  similar  to  level  1 but  specific  for  a failure) 
and  level  3 works  with  the  relations  between  differ- 
ent failures  in  different  components. 

Details  about  these  generic  algorithms  for  handling  tem- 
poral, semantical  and  spatial  conflicts  can  be  found  in 
[DIAMOND]. 

4.6  Facilitator  Agent 

The  Facilitator  Agent  is  responsible  for  networking  and 
mediating  between  the  agents  in  the  Multi-Agent  frame- 
work. Large  industrial  applications  may  be  federal  and 
hierarchical  structured.  This  structure  is  adopted  to  dif- 
ferent “domains”.  A domain  is  a subsystem  of  the 
DIAMOND  architecture  that  is  responsible  for  a part  of 
the  industrial  application.  Each  “domain”  is  associated 
with  a facilitator  agent  to  facilitate  the  networking  within 
this  domain  and  with  other  Facilitator  agents  of  other 
domains.  Thus  a diagnosis  of  a single  domain  as  well  as 
a diagnosis  of  the  complete  industrial  application  is  fea- 
sible. Furthermore,  the  Facilitator  agent  is  the  mediator 
to  the  Graphical  User  Interface  Agent. 

4.7  Blackboard  Agent 

All  diagnosis  results  that  were  reported  within  a well 
defined  timeframe  are  stored  in  a blackboard  that  is  im- 
plemented in  a Blackboard  Agent.  Each  domain  has  its 
own  Blackboard  Agent  that  is  mediating  with  the  Con- 
flict Resolution  Agent.  The  Blackboard  Agent  provides 
the  results,  reported  by  the  Diagnostic  Agents  and  trig- 
gers the  conflict  resolution  process.  The  resolved  diag- 
nostic result  that  cover  the  state  of  all  components  that 
are  part  of  the  domain  are  forwarded  to  the  Facilitator 
Agent.  The  Blackboard  Agent  is  also  in  charge  of  storing 
all  reported  diagnostic  results  permanently. 

4.8  Graphical  User  Interface  Agent 

The  Graphical  User  Interface  Agent  is  the  human  gate- 
way to  the  DIAMOND  system.  The  operator  uses  this 


interface  to  get  information  about  the  state  of  the  indus- 
trial application,  to  provide  human  accessible  informa- 
tion to  the  Diagnostic  Agent  and  to  initiate  diagnostic 
processes. 

4.9  Overall  Architecture 

The  hierarchical  and  federal  structure  of  the  industrial 
environment  that  has  to  be  monitored  and  diagnosed  is 
transferred  to  a hierarchical  and  federal  structure  of  the 
software  architecture.  For  this  purpose,  industrial  com- 
ponents are  grouped  together  to  form  a logical  superior 
unit.  A set  of  agents  that  are  responsible  for  diagnosing 
this  set  of  components  are  grouped  within  a “domain”. 
Only  the  Facilitator  Agent  of  each  domain  is  able  to 
communicate  with  other  Facilitator  of  other  domains  or 
with  the  Graphical  User  Interface  Agent. 

The  main  concepts  of  this  DIAMOND  architecture  are 
summarized  in  figure  2. 


provide  measurements  that  may  be  used  by  the  Diagnos- 
tic Agents  of  different  domains. 

5 How  to  build  a monitoring  and  di- 
agnosis system 

This  chapter  describes  the  steps  that  are  required  to  build 
up  a complete  monitoring  and  diagnosis  system  by  using 
the  results  provided  by  the  DIAMOND  architecture. 

5.1  Identify  semantic  structure  of  the  in- 
dustrial application 

The  first  step  while  building  up  a monitoring  and  diagno- 
sis system  is  to  define  all  physical  components  and  their 
relations  of  the  automated  industrial  system  that  have  to 
be  supervised.  There  should  be  no  overlap  between  com- 
ponents, nor  should  there  be  “white  spaces”  of  the  sys- 
tem being  diagnosed  not  covered  by  a component  at  all. 
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Figure  2 DIAMOND  Architecture 


All  DIAMOND  agents  that  are  interacting  are  pictured  as 
two  colored  boxes  with  the  type  of  the  agent  written  in- 
side. The  light  green  box  indicates  the  Wrapper  that  is 
responsible  for  communication.  This  part  is  unique  for 
all  agents.  The  second  box  represents  the  Brain  which  is 
specific  for  the  agents  type.  The  agents  are  interacting  by 
using  the  Object  Request  Broker  (CORBA).  This  mid- 
dleware is  pictured  as  the  yellow  bar  in  the  middle  of  the 
figure. 

The  figure  indicates  three  different  domains  (Domain  A, 
B and  C).  These  domains  are  grouping  the  Diagnostic 
Agents,  a Blackboard  Agent,  a Conflict  Resolution  Agent 
and  a Facilitator  Agent  together.  The  Monitoring  Agents 
are  not  associated  to  one  single  domain.  They  are  able  to 


The  components  of  the  industrial  application  may  be  hi- 
erarchical or  federal  related  with  each  other.  If  there  is  a 
set  of  components  that  are  building  a logical  unit  which 
is  widely  self-contained,  they  have  to  be  grouped  to- 
gether into  a domain.  The  knowledge  about  the  compo- 
nents and  domains  is  fixed  for  a specific  industrial  appli- 
cation and  will  not  change  during  runtime.  DIAMOND 
provides  an  ontology  that  defines  the  structure  and  the 
possible  attributes  of  any  component.  This  knowledge  is 
stored  in  the  structural  knowledge  base  in  the  XML  for- 
mat. 

The  possible  relations  between  components  are  ex- 
pressed by  the  attributes  of  each  “COMPONENT”  ele- 
ment: 


• INPUT_CONNECTED_TO  specifies  functional  or 
logical  output  of  another  component  which  effects 
the  behavior  of  this  component. 

• EXCLUSIVE  identifies  that  the  faults  of  both  related 
components  are  mutual  to  each  other. 

• BELONGING_TO  is  used  to  express  the  topological 
relation  between  “parent”  and  “child”  components. 

Further  attributes  are  the  certainty  of  the  identified  rela- 
tion and  a possible  time  delay  which  describes  the  tem- 
poral behavior  of  related  components. 

5.2  Identify  measurements 

It  has  to  be  investigated  whether  there  are  any  existing 
monitoring  sources  available  which  are  able  to  access 
measurable  states  of  the  plant.  These  sources  may  be 
accessed  by  a Monitoring  Agent.  It  has  to  be  investi- 
gated, which  information  about  the  measurable  state  of 
the  industrial  application  is  accessible  and  how  to  obtain 
them.  In  the  case  of  integrating  a legacy  application  for 
accessing  the  system  variables,  the  interface  to  these  ap- 
plications have  to  be  identified.  All  measurable  states 
that  are  practical  for  a diagnosis  have  to  be  described  as 
a measurement  according  to  a well  defined  ontology  for 
MEASUREMENT. 

All  measurements  that  will  be  used  have  to  be  associated 
with  a Monitoring  Agent  that  is  able  to  access  it.  It  is 
reasonable  to  associate  all  measurements  that  are  pro- 
vided by  a single  data  acquisition  source  or  by  a specific 
mechanism  how  to  access  them  with  the  same  Monitoring 
Agent. 

5.3  Identify  failure  modes 

The  M&D  system  is  able  to  identify  those  potential  faults 
of  the  industrial  application  that  were  specified  in  ad- 
vance. Therefore,  it  has  to  be  investigated,  which  legacy 
diagnostic  tools  may  be  used  and  which  faults  these 
modules  are  able  to  detect. 

Attributes  for  each  failure  are  specifying  the  conditions 
that  have  to  be  fulfilled,  the  names  of  rules  that  are  fea- 
sible to  identify  the  fault  and  potential  recovery  actions. 
Another  attribute  identifies  whether  the  occurrence  of 
this  failure  is  related  with  another  failure,  either  in  the 
same  or  in  another  component.  This  allows  to  state 
whether  different  faults  are  contradicting  or  comple- 
menting each  other,  how  they  are  temporally  related  and 
how  a failure  propagates. 

All  these  information  are  stored  within  an  XML  struc- 
ture. These  data  are  mainly  processed  by  the  Conflict 
Resolution  Agent  to  solve  diagnostic  conflicts.  The  diag- 
nostic mechanisms  and  algorithms  to  identify  the  failure 
are  specific  to  the  industrial  process  and  will  be  used  by 
the  diagnostic  agents. 

5.4  Build  Monitoring  Agents  and  connect 
with  industrial  environment 

For  building  the  Monitoring  Agents,  a shell  is  provided 
by  DIAMOND  that  enables  the  creation  of  this  agent. 
The  connection  with  the  monitoring  and  diagnostic  infra- 


structure is  automatically  realized.  The  connection  with 
the  sensors  of  the  industrial  application  has  to  be  done 
afterwards.  This  task  is  specific  for  each  application  and 
for  each  sensor. 

There  are  several  predefined  configuration  parameters 
for  a Monitoring  Agent.  These  parameters  may  be  set  by 
using  a DIAMOND  toolkit. 

5.5  Build  Diagnostic  Agents  and  connect 
with  diagnostic  engines 

The  measurements  are  used  by  the  Diagnostic  Agents  to 
perform  a diagnosis.  For  this  purpose,  each  Diagnostic 
Agent  needs  to  have  a diagnostic  engine.  This  may  be  a 
commercial  expert  system  or  any  other  kind  of  diagnostic 
engine  to  identify  failures  of  the  related  component.  The 
connection  of  the  diagnostic  engine  with  the  M&D  sys- 
tem is  realized  by  using  a development  shell  for  creating 
the  Diagnostic  Agents.  The  interface  to  the  diagnostic 
engine  has  to  be  implemented  afterwards  individually. 
There  are  only  two  methods  that  have  to  be  implemented 
for  interfacing: 

One  method  enables  the  diagnostic  engine  to  get  a meas- 
urement value  which  is  accessed  from  an  internal  buffer 
of  the  Diagnostic  Agent.  The  engine  does  not  keep  care 
where  to  get  the  measurement  from.  All  measurements 
that  were  identified  in  chapter  5.2  are  accessible.  After 
the  engine  has  performed  its  diagnosis,  it  provides  the 
diagnosis  result  to  the  Wrapper  of  the  agent  by  using  the 
second  method  of  the  interface.  The  Wrapper  makes  the 
result  available  for  the  infrastructure  for  further  proc- 
essing. 

Integrating  the  diagnostic  engine  of  a legacy  diagnostic 
tool  is  possible,  if  this  clear  interface  is  realized.  No 
further  modifications,  neither  to  the  DIAMOND  frame- 
work, nor  to  the  diagnostic  engine  are  required. 

6 Evaluation  Examples 

The  functionality  of  the  presented  multi-agent  architec- 
ture was  verified  by  integrating  a specific  monitoring  and 
diagnosis  system  into  two  operational  prototypes. 

The  first  was  concerned  with  the  functional  process  of  an 
automated  welding  cell,  containing  a control  system,  a 
robot  with  gas-metal  arc  welding  equipment  and  a posi- 
tioning device.  To  simulate  faults  that  may  occur  in  the 
welding  system,  a simulator  was  used  that  emulates  the 
behavior  of  the  welding  equipment  for  different  faulty 
situations.  The  measurements  were  accessed  by  using  an 
ODBC  interface  and  a DCOM  interface.  Several  legacy 
case  based  reasoning  engines,  each  responsible  for  an- 
other component,  were  applied  to  identify  faulty  compo- 
nents. This  integration  was  suitable  to  present  the  capa- 
bility to  integrate  different  data  accessing  methods  and 
various  diagnostic  engines  within  an  integrative  moni- 
toring and  diagnostic  system  easily.  This  M&D  system 
was  able  to  identify  spatial  conflicts  and  recognize  the 
propagation  of  faults  from  one  component  to  another 
one. 


The  second  evaluation  example  took  an  existing  expert 
system  for  diagnosing  the  water-steam  cycle  chemistry  of 
a coal  fired  power  plant  (called  SEQA,  based  on  G2, 
Gensym)  and  re-worked  it  to  operate  in  a modern  diag- 
nostic framework.  To  verify  the  behavior  of  the  M&D 
system  outside  the  power  plant,  a simulator  based  on  a 
neural  network  model  was  used  to  either  generate  offline 
artificial  anomalies  overlapped  to  normal  patterns  or  on- 
line to  provide  a set  of  normal  behavior  values  against 
which  measurements  should  be  compared.  The  assimila- 
tion of  a complete  legacy  expert  system  into  a distrib- 
uted M&D  framework  illustrated  a complex  tasks  since 
there  were  many  interfaces  necessary  for  accessing  data 
and  for  using  the  legacy  diagnostic  engines. 

7 Conclusion 

This  paper  describes  a concept  for  building  a distributed 
architecture  for  monitoring  and  diagnosing  a complex 
industrial  application.  The  presented  M&D  system  uses  a 
multi  agent  approach  which  warrants  the  flexibility,  the 
extendibility  and  a cost  effective  development  of  the 
system. 

One  main  extension  to  existing  solutions  is  the  possibil- 
ity to  integrate  legacy  diagnostic  tools  into  the  overall 
diagnosis  system.  This  requires  an  extensive  and  exact 
specification  of  all  components,  measurements  and  pos- 
sible failures  of  the  industrial  application  as  well  as  a 
specification  of  their  relations  to  each  other.  This  was 
realized  by  introducing  a set  of  ontologies  for  the  moni- 
toring and  diagnostic  system. 

Furthermore,  several  diagnostic  engines  can  be  utilized 
in  parallel.  They  may  refer  to  different  components  of 
the  industrial  application  and  they  may  apply  different 
diagnostic  mechanisms.  By  using  different  Diagnostic 
Agents,  related  to  different  components,  the  diagnostic 
knowledge  can  be  provided  by  the  component  manufac- 
turer. For  applying  different  diagnostic  methods,  algo- 
rithms were  developed  to  handle  different  diagnosis  re- 
sults in  parallel  and  to  investigate  whether  they  are  com- 
pleting or  contradicting  each  other. 
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